A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
A Computer Program Listing Appendix, containing five (5) total files on compact disc, is included with this application.
The present invention relates generally to information processing environments and, more particularly, to access and processing of information in a data processing system embodied, at least in part, in portable devices.
Computers are very powerful tools for storing and providing access to vast amounts of information. Computer databases are a common mechanism for storing information on computer systems while providing easy access to users. A typical database is an organized collection of related information stored as xe2x80x9crecordsxe2x80x9d having xe2x80x9cfieldsxe2x80x9d of information. As an example, a database of employees may have a record for each employee where each record contains fields designating specifics about the employee, such as name, home address, salary, and the like.
Between the actual physical database itself (i.e., the data actually stored on a storage device) and the users of the system, a database management system or DBMS is typically provided as a software cushion or layer. In essence, the DBMS shields the database user from knowing or even caring about underlying hardware-level details. Typically, all requests from users for access to the data are processed by the DBMS. For example, information may be added or removed from data files, information retrieved from or updated in such files, and so forth, all without user knowledge of underlying system implementation. In this manner, the DBMS provides users with a conceptual view of the database that is removed from the hardware level.
The general construction and operation of a database management system is known in the art. See e.g., Date, C., An Introduction to Database Systems, Volume I and II, Addison Wesley, 1990; the disclosure of which is hereby incorporated by reference.
DBMS systems have long since moved from a centralized mainframe environment to a de-centralized or distributed environment. One or more PC xe2x80x9cclientxe2x80x9d systems, for instance, may be connected via a network to one or more server-based database systems (SQL database server), to form a client/server database system. In operation, clients issue one or more query language (e.g., SQL) commands to the server. A query language is a specialized language for accessing or processing information from a database. SQL commands may, for instance, specify a query for retrieving particular data (i.e., data records meeting the query condition) from a database table. The syntax of SQL (Structured Query Language) is well documented; see, e.g., the abovementioned An Introduction to Database Systems. As used herein, xe2x80x9cSQLxe2x80x9d shall also include vendor-specific variants of SQL, such as Sybase(copyright) Transact-SQL. In addition to retrieving the data from database server tables, the clients also include the ability to insert new rows of data records into the table; clients can also modify and/or delete existing records in the table. Commercial examples of these xe2x80x9cclient/serverxe2x80x9d systems include Powersoft(trademark) clients connected to one or more Sybase Adaptive Server(trademark) database servers. Both Powersoft(trademark) and Sybase Adaptive Server(trademark) (formerly Sybase SQL Server(trademark)) are available from Sybase, Inc. of Emeryville, Calif.
As the migration to client/server continues, each day more and more businesses are run from mission-critical systems which store information on SQL-based database systems. At the same time, there is much interest in decreasing the physical requirements of such systems, so that such systems can provide decision support not only from servers but also from portable, hand-held devices. Currently, however, database application development on small footprint devices or xe2x80x9cultralightxe2x80x9d devices involves hand coding any database functionality and host database synchronization. At the same time, users expect the productivity and reliability advantages of using a SQL database, while maintaining the size and performance advantages of hand-coded applications.
What is needed is a database development environment enabling the creation and deployment of database applications which are more portable across multiple devices, including ones having limited computational power. At the same time, however, such database applications would include the productivity and reliability advantages of a SQL database. The present invention fulfills this and other needs.
A database development environment (referred to herein as the xe2x80x9cUltraLitexe2x80x9d database development system or environment) capable of creating a database application that is more portable across multiple devices, including ones having limited computational power, is described. UltraLite includes development tools and methodology that allow the development of database applications for these devices. The applications themselves can incorporate SQL statements (i.e., standard query language statements) and SQL cursors for use against data sources, including UltraLite databases (i.e., databases created by the UltraLite system). UltraLite includes the ability to synchronize data in an UltraLite program (i.e., program created by the UltraLite system) with data in a host SQL database.
The UltraLite development environment generates code to process the SQL in the application. The application code and generated code are compiled and then linked with the UltraLite runtime library. The result is an UltraLite program that includes application logic and database logic together in a single program. Multiple applications that share the same database are linked as a single UltraLite program. The footprint for an UltraLite program is minimized, to be generally less than 100K. This includes support for synchronization, but excludes memory requirements for the actual data in the database. The footprint of the database logic in the program will depend mostly on the amount of SQL and the features used (e.g., data types, operators, and SQL built-in functions). Fixed overhead is minimized; in the currently-preferred embodiment, for instance, there is no separate database engine.
UltraLite databases are preferably implemented as data structures within an UltraLite program. An UltraLite database preferably only exists in memory. Persistence of an UltraLite database is accomplished by using one of two common methods for handheld devices: using persistent memory (static memory or flash memory) or having the UltraLite program run forever.
UltraLite applications, which may be authored in the UltraLite environment, are typically written in the C programming language and use static embedded SQL to specify SQL statements and cursors within applications. An UltraLite Pre-compiler is employed to process embedded SQL (or other query language statements) in source files (e.g., C files) and generate new source files (e.g., still C files) without the embedded SQL. The environment includes, at its core, an xe2x80x9cAnalyzerxe2x80x9d which receives SQL from the Pre-compiler and submits the SQL to an available database server (e.g., Sybase Adaptive Server Anywhere) for parsing and optimization. The Analyzer uses the database server""s (i.e., the database server of Adaptive Server Anywhere) access plans and schema information to generate C code to execute the SQL statements.
In the currently-preferred embodiment, an UltraLite application does not employ dynamic SQL. An UltraLite database has no system tables, no SQL parser, and no optimizer. The SQL statements, cursors, and access plans are instead determined when the code for the program is generated. Host variables in static embedded SQL allow values in the application logic to be incorporated into SQL queries, but they do not allow changes to table or column names in the currently-preferred embodiment. For example, the same data sorted two different ways will require two SQL cursors with different ORDER BY clauses.
The target platforms for UltraLite include standard development platforms, such as Windows NT, to allow application developers to develop and test the database logic in their application without needing to download the UltraLite program to the real target device. This is especially important when the debugging features available on the real target device are crude. Some target devices may also provide an emulator for the device on the UltraLite development environment, allowing the application developer to develop, test, and debug the entire application (including user interface) in a single environment.
Specific method steps of the overall process of development of an UltraLite database application are as follows. First, the user creates in a source code editor one or more source code files for the database application program under development; the source code includes SQL statements. The Pre-compiler of the system parses the source code files and provides the parsed information to the Analyzer. The Analyzer passes the SQL statements to the RDBMS for formulating the data access, including an access plan, optimizations, and database cursors. Moreover, the Analyzer creates appropriate data structures and methods in the application program for a creating, accessing, and processing a run-time version of the database. Based on the foregoing, the system creates new source code files which include native source code statements replacing the abovementioned SQL statements. Now, the source code is ready for compilation. Specifically, the source code files are compiled by the Compiler into one or more object modules. The Linker links the object modules with the runtime libraries and emits a compiled application program. The application program includes both application logic and database logic for accessing a target database embedded within the program.